Summary

Fix firewall rule discovery so flag-like substrings inside chain names and quoted values are not parsed as real iptables options.

Today rule_to_hash in lib/puppet/provider/firewall/firewall.rb parses most attributes by scanning the full raw iptables-save line with regexes. That allows matches to happen in places that are not real option tokens, for example:

• chain names that end with -p
• chain names that contain -A
• quoted values such as comments or other quoted payloads

On affected systems this can cause the parser to manufacture malformed values such as proto => '-p'. Once that happens, process_get receives an invalid proto value and discovery can later fail with:

Unsupported proto number: -p

This change fixes the parser at the source by:

• requiring token boundaries when matching iptables flags, so options are only parsed when they appear as real tokens
• continuing to ignore quoted payloads when parsing non-quoted attributes
• continuing to parse quoted attributes from the original rule text
• preserving existing behavior for real protocol flags such as -p tcp
• preserving the existing proto => all fallback when no real protocol is present

It does not change utility.rb and does not change firewallchain.rb.

Additional Context

• Root cause and the steps to reproduce. (If applicable)
• Thought process behind the implementation.

Root cause / reproduction

On affected systems, iptables-save output can contain rules where the raw line includes flag-like substrings that are not real option tokens, for example:

• a chain name ending in -p, followed by a real -p udp
• a chain name containing -A
• quoted payloads containing text such as -p -p or ! -p -p

Because rule_to_hash scans the full raw rule line, those substrings can be mistaken for real options. In the failing case, the parser can store proto => '-p', and later in discovery this surfaces as:

Unsupported proto number: -p

This can cause Puppet::Type.type(:firewall).instances to fail during rule discovery and can also break firewallchain resource generation that depends on discovered firewall state.

Thought process behind the implementation

The goal of this change is to fix the root cause in the provider parser rather than make downstream protocol conversion more tolerant of malformed intermediate values.

process_get already handles a missing protocol by defaulting to all, so the correct fix is to stop rule_to_hash from manufacturing invalid protocol values in the first place.

Using token-boundary-aware matching ensures that flags such as -p and -A are only parsed when they appear as real iptables option tokens, not when they appear inside chain names or other arbitrary substrings. Quoted payload masking is still kept for the non-quoted parsing branches so quoted content is not interpreted as flags.

Test Coverage

Also adds provider test coverage for:

• unit parsing: quoted comments containing -p -p do not set proto
• unit parsing: quoted comments containing ! -p -p do not set proto
• unit parsing: single-quoted comment payloads do not set proto
• unit parsing: a real -p tcp outside quotes still parses as proto => tcp
• unit parsing: chain names ending in -p do not cause proto => '-p'
• unit parsing: chain names containing -A do not confuse chain parsing
• end-to-end parsing: get returns proto => all when no real protocol is present
• end-to-end parsing: get does not surface -p / ! -p as protocol values
• end-to-end parsing: rules on chains with names containing -p still parse the real protocol correctly

Related Issues (if any)

No linked issue yet.

Checklist

• 🟢 Spec tests.
• 🟢 Acceptance tests:
  Acceptance tests were not run locally because Docker/Litmus provisioning is not available in my environment.
• Manually verified. (For example puppet agent -t on an affected system)